Initially, a number of terms will be defined. As used herein, “Identity” refers to the characteristics determining who or what a person or thing is. A “Legal Identity” is a set of identifying attributes, as designated by a 3rd Party, which are used for verification, validation and authentication. A “Digital Legal Identity” is a digital equivalent of a Legal Identity. A “Digital Identity” (DI) is a role-based digital identity that is created, controlled and managed by an individual and is used for verification, validation and authentication. Every individual has real identity attributes, such as name, email address, physical address, telephone number and the like. A digital identity has digital identity attributes operative as a personal privacy proxy with compartmental identity attributes. For example, a first digital identity may have a name, email address, physical address and telephone number different than the real identity attributes and also different than a second digital identity.
Internet users face a barrage of tracking functions that monitor the websites they visit, the pages they read, and the online activities they perform. To expand this user profiling, current and emerging tracking technologies compare activities across multiple websites and use Artificial Intelligence (AI) to make inferences based on information collected about each user.
One common method of correlating a user's personal information and their online activities is to index those data items by a data item that is usually unchangeable and common across all of a user's various online activities. This ‘indexing data item’ functions as a ‘primary indexing key’ to correlating a user's various types of personal and activity information. The problem with primary indexing keys is that they are either unchangeable (e.g., social security account number) or they are cumbersome to change as they cascade into changing numerous other accounts. The latter is the case with phone numbers, social media credentials, login names, email addresses, etc. This has created a dilemma for users who find it both useful and potentially risky to give out that information.
One common method of disrupting the correlation of a user's personal information with their online activity information is to change or alter the primary indexing key being used by analytics gathering methods. In some scenarios, users may obtain new phone numbers or email addresses in order to segment their activities and thereby block correlation. Anonyome Labs®, San Francisco, Calif. distributes an application called Sudo® to manage digital identities. The application allows users to create and manage multiple email addresses (also phone numbers and credit card numbers) so as to disrupt user tracking activities. Using such applications, users may create a new digital identity to isolate one set of their online activities from another set of online activities. For example, this helps users compartmentalize their work activities from their other activities related to other interests such as social, political, medical, etc.
Creating new digital identities helps users to compartmentalize classes or types of online activities (e.g., to keep online work activities separate from social activities). However, each class of activity (e.g., personal versus work) can also be subdivided into numerous roles, such as: sending/receiving of email, purchasing, newsletter subscriptions, web researching, personal medical research, etc.
Over time, analytics gathering entities can collect sufficient personal and online activity details to ‘paint a picture’ or model the user's created digital identity. This opens the digital identity to some of the same tracking and profiling activities that are currently directed at real-world users.
In one scenario, a user may have created a well-defined digital identity (including a corresponding email address) that is functioning perfectly to suit the user's needs. Using that digital identity, the user may have created well-established connections via social media, children's sporting activities, payment providers, or even a medical history. In this instance, the digital identity is functioning as desired. Then, without warning, the user may inadvertently disclose the digital identity's email address to someone that they previously did not know was a spammer or otherwise engaged in online usage tracking activities. At this point, the user's digital identity starts to be tracked, receives spam email, or other undesired solicitations that cannot be stopped.
In the above scenario, one resolution is that the user could change the digital identity's email address or even delete the digital identity in order to block the tracking or spamming activities. While these are perfectly legitimate solutions, they may require the user to re-build the digital identity with a new email (or other digital identity information such as a phone number or login name) and then re-connect the new information to each of the legitimate activities, websites, and/or people previously connected to the original digital identity. This could disrupt user activities, because, once given out, an email address cannot readily be replaced without a lot of effort.
Another resolution to the above scenario would make disconnecting from the spammer much simpler if the user had sub-divided the digital identity into roles. In this usage, a digital identity role would be limited to a specific activity within the scope of numerous activities related to a user's digital identity. For example, a role might be limited to a user's medical appointments with a doctor(s). In this case, a user might have a role-specific email address used to sign up with a doctor's office to receive email reminders of upcoming visits. Creating a role-specific email address allows the user to specifically limit that particular email address to personal doctor(s). With role-specific emails, it will be easy to identify the email address used by a spammer. Additionally, a role's email address is likely only used by one (or few) role recipients. In this case, if a user wants to delete or change the email address associated with a role, it is much simpler to clean up the results of an email address being compromised by a spammer, linked to analytics gathering, or otherwise used inappropriately. Even removing an entire role is a much simpler solution than deleting, re-creating, and then re-connecting a new digital identity that was otherwise functioning satisfactorily.
One embodiment of the role-based solution can be implemented with the process defined in RFC 5233 (https://tools.ietf.or/html/rfc5233). RFC 5233 describes a method of ‘sub-addressing’ or ‘detailed addressing’ of email addresses. For example, an email server may define a method of sub-addressing that it can interpret while still being compliant with modern email standards. The following example shows how a standard email may be sub-addressed to form a technically different email address, but an email address that can still be correlated to a real user.
Main Email: johndoe@example.com
Sub-Address #1: ebay+johndoe@example.com
Sub-Address #2 amazon+johndoe@example.com
With the RFC 5233-based hierarchy of email address shown above, users can give a unique email to their various role activities. With the RFC 5233 implementation, the implementing email server will define a separator character such as ‘+’. This allows users to easily create new sub-addresses and also enables the server to deterministically recognize, sort, and route all incoming traffic to each of the 3 email addresses to the same inbox.
However, RFC 5233 also defines that the non-root subpart of the email address (e.g., ‘ebay’ or ‘amazon’ from the addresses shown above), will allow email clients and servers to automatically sort or categorize emails arriving at each of the addresses. This is done by the server stripping off the non-root portion and the separator character, so that the root email address remains. In this scenario, the root email addressed is used to deliver incoming emails to the user's inbox and the non-root portion is used to help the user's inbox separate the incoming emails into folders designated by the non-root email portion. For example, a user may have a sub-inbox called ‘amazon’ where only the ‘amazon’ emails are collected. This process greatly simplifies inbox management.
The downside of the RFC 5233 method is that websites seeking to collect personal information and track users have little problem analyzing addresses and quickly recognizing the separator character and the subparts of the email address. Although different email providers can choose a different separator character and nefarious websites will need to recognize the separator character and the sub-parts of the address, it is reasonable to presume that this is a fairly simplistic process and will quickly be mapped.
If a nefarious website collects email addresses and decodes the ‘user’ or ‘local-part’ (i.e., the portion of an email address before the ‘@’ symbol) of the email address, then they can easily continue to email the user's root email address regardless of whether the user has intentionally deleted the sub-address previously given to the nefarious website. Thus, there is a need for improved techniques for managing digital identity credentials.